前面提到靜態測試就是不藉由執行受測程式的方式, 來進行相關的測試.
那這種方式真的可以找到問題嗎? 可以帶給我們怎樣的好處呢? 主要是從以下面向的來討論
當在前期時, 大家就起來確認內容, 可以避免後續需要大改, 減少重做的機會. 也因為被檢視過, 所以在開發的時候, 會比較有信心, 這樣的方向大致上是正確的, 比較不會患得患失的.
根據前面所說的, 越前面找到錯誤, 修復的成本越低, 修復的時間也較少. 以前我們是前面衝很快, 但是後面就花了大量的時間去修 bug. 給人感覺你很快寫好, 但是總體交付時間卻是大大的拉長. 所以看你是前面花時間, 還是要後面花時間.
大家一起開發來完成某個產品, 不可能彼此都沒關聯. 因此早期能夠相互瞭解彼此的程式結構, 其他人是怎麼設計, 會對自己產生什麼影響, 早期就知道可以避免日後返工. 並且也可以順便檢查, 同事們是否遵從 coding standard, 確保風格結構一致, 這樣日後要維護, 才會比較容易.
哪些可以使用靜態測試來驗證? 大致有以下東西
基本上, 開發中間的所有產出可以被驗證. 不管他是不是給外面的用戶, 只要是之後會被其他人使用, 都可以拿來被驗證.
以下. 我們就開始詳細介紹各個靜態測試的作法.
圖 8-1 靜態測試的種類
代碼檢視 (Code Review)
根據 wiki 的定義, code review 是是指對程式碼進行系統化地檢查, 常用Peer Review的方式進行, 目的是在找出及修正在軟體開發初期未發現的錯誤, 提升軟體品質及開發者的技術.
所以進行的時機, 就是你寫到一個段落後就可以做了. 最好不要是出包後, 才後要檢視他做的東西, 作者在被威脅的狀況下, 整個過程就很容易是在狡辯和反抗的狀況下, 大家不會放開心胸, 並且一心只想避免被抓到問題.
其實這應該是個學習機會, 讓你有機會多了解不同做法, 學習別人的經驗.
圖 8-2 Code Review
所以 Code Review 有以下好處
程式會有錯, 其中一個可能的原因, 就是你只想到自己想到的狀況, 導致程式沒有去處理到這些例外狀況.多點人一起看, 尤其是不同職能, 可以看到不同的面向. 尤其是測試人員和客戶, 他們的面向往往是和開發人員不大相同.
強迫遵循 coding standard
加速學習
對於新人來說, 這是個很好機會, 可以了解系統是如何運作, 以及如何才能把程式寫好. 另外, 即使你待了一陣子, 你也不見得全懂, 或者你也可能不知道其他同事在做什麼, 藉由這個機會可以讓你知道.
老實說, 很多時候我們常常是相同錯誤一再發生, 因此我們可以透過一些 checking list, 在 code review 的時候提醒大家, 這些面向的事情要注意, 成本不高, 但是效果其實不錯.
檢查 (Inspection)
Software Inspection是針對軟體工作文件, 例如:需求規格, 設計文件, 測試計畫/測試個案, 由受過訓練的人員進行, 使用明確定義的流程, 來找到軟體中的缺陷.
它和前面 Code Review的不同, 就是它分工明確, 每個角色要做什麼有規定清楚, 並且流程也是什麼嚴謹. 首先, 就讓我們來看看他有那些角色以及他們的責任是什麼
協調者 (Moderator)
協調者會先找到要參與的相關角色. 跟他們說他們要負責什麼事情, 並且訂出時程, 請大家按計劃進行.
在檢視過程中, 要確保討論在控制中, 不會因此吵架, 或者討論範圍歪樓. 當檢視完畢後, 也要確定後續有追蹤這些找出來的問題有被處理
報告者 (Reader)
報告者簡報要被檢視的內容, 幫助與會者快速了解內容. 這易做的好處, 一方面是確保有人真的會看, 因為報告者不看, 他是無法引領大家導讀. 另一方面, 是避免由作者解釋, 會花比較多時間在為自己的內容辯護, 過程會比較中立.
作者 (Author)
在檢視會議過程中, 如果有人對內容有疑問時, 作者會解釋背後的理由, 幫助大家可以了解其背景.
要記住的, 作者不能是紀錄者, 避免紀錄內容會避重就輕. 作者也不能當協調者或是報告的人, 避免容易立場有失公允.
在這個過程中, 作者可以從參與的人學習到不同意見, 對他來說很有幫助.
記錄者 (Recorder)
記錄者會記錄過程中找到的問題, 並且最後產生報告, 讓作者可以根據此內容修正. 協調者可以根據這些內容確認作者是否都有處理
檢驗者 (Inspector)
檢驗者需要看完要檢視的內容, 在討論過程中提出問題, 並且建議解法
在了解完各個角色要做什麼, 接著我們來看 Software Inspection的流程為何. 如圖 8-3所示, 分成以下階段
圖 8-3 Software Inspection 的流程
規劃 (Planning)
協調者會確認時程, 以及要參與的人有誰, 扮演什麼角色
開始 (Kick off)
協調者接著會召開Kick off 會議, 把所有角色的人找來, 解釋會議的目的, 時程, 以及要注意的事情. 並且給大家要檢視的內容.
準備 (Preparation)
檢視者會在這段時間閱讀要檢視的內容, 紀錄所找到的問題. 並且會送給紀錄者, 讓他先把這些找到的問題整合起來.
檢視會議 (Review Meeting)
所有人一起來開這個會議. 報告者導讀要被檢視的內容, 檢視者可以補充或是提問, 作者可以解釋.
如果確認所提出的問題是問題, 紀錄者會記錄下來, 但是在當下是不討論解法的
修正 (Rework)
作者會根據會議紀錄, 逐條修正. 如果需要進一步討論, 會去找相關的人一起研究.
後續確認 (Follow Up)
協調者會確認作者是否按照會議記錄的內容, 把所有相關問題都處理了
搭擋編程 (Pair Programming)
搭擋編程 (Pair Programming) 是一種敏捷軟體開發中的一個實踐(practice)，兩個程式設計師在一個電腦上共同工作. 一個人撰寫程式, 而另一個人審查他輸入的每一行程式. 兩個人員會經常互換角色.
圖 8-4 搭擋編程的狀況
這兩個人的名稱如下:
導航員 (Navigator)
會觀察有狀況的地方, 中間過程會不斷地問問題, 會和另一個人一起腦力激盪和規劃
駕駛員 (Driver)
真正撰寫程式, 或是打字的人, 他會解釋他所做的事情, 並且和導航員一起腦力激盪和規劃.
為什麼我們要進行搭擋編程呢? 很多老闆或是工程師會覺得這樣似乎浪費資源和時間, 兩個人坐同一份工作噎. 但是, 事實上並不是這樣, 它可以帶來以下好處：
在開始撰寫階段, 就有另一雙眼睛在看你的產出, 錯誤比較不會被遺漏. 此外兩個人一起看, 也可以消除盲點, 避免自己以為事情只有這樣.
因為有人盯著看, 並且不斷討論, 所以你很難摸魚. 並且如果你不專心, 另一個人會看得出來, 並且你也容易回答不上話.
一起緊密工作, 可以知道對方的想法, 比較容易建立起感情, 一起工作互助的革命情感.
這一點在前面已經提過不在重述.
這一點在前面已經提過不在重述.
搭擋編程可以經常換伙伴, 只要一個小功能做完後, 就可以換人一起寫, 不同夥伴可以帶來不同的感受, 可以讓你工作時有不同的樂趣.
靜態分析 (Static Analysis)
靜態分析(Static Analysis) 是指在不執行程式的條件下，利用工具進行程式分析的方法. 所以他的重點在於工具, 是以自動化的方式來執行, 並不是像前面幾種, 都是以人工的作法.
這裡可以分析的對象可能是 原始程式碼 Source code 或是 編譯後的代碼 Object code. 看工具可以支援的程度.
那何時會使用這些工具呢? 一種是開發階段就開始使用. 另一個是等到測試階段才用. 不過因為他是自動化, 不用人介入, 如果可以的話, 早點開始, 早期投入, 找出的問題比較容易修復. 因為後面才用的話, 往往都是找出幾百條問題, 那時候就會沒人想改.
圖 8-5 靜態分析架構
通常我們會把這個工具, 放到持續整合的管道中一起執行. 如圖 8-6 所示. 如果靜態分析在程式建構之前, 可以弄成分析有找到問題, 便不讓他進行建構, 可以強制開發人員找到時就要處理, 避免後期來不及解完.
圖 8-6 靜態分析與 CI 整合
在挑選靜態分析工具時, 我們會考慮以下因素
支援的語言 可支援專案中所使用的程式語言, 支援越多語言越划算
整合能力 容易和上述其他CI工具或環境(Mac, win, Linux 等)整合
價格 整個部門或公司使用都還划算
可擴充性 將來可支援新的語言或檢查規則
那靜態分析工具可以抓到哪些問題或是應用到哪邊呢? 大致上可以分成以下幾類:
絕大多數會跑靜態分析工具, 主要都是要抓安全漏洞(vulnerability). 因為這個部分除了程式品質不好外, 也會影響商譽, 並且還可能受到駭客的勒索.
有些工具可以檢查瓶頸出在哪裡, 哪邊執行需要比較多時間, 哪邊會使用較多的系統資源. 讓你可以直搗黃龍, 快速修復效能問題.
因為他是個工具, 所以我們就會想要收編到持續整合或是持續部署平台中. 讓他可以每次 check-in 或者每次建構時都執行.
識別潛在的違規行為, 確保符合特定的法律要求, 例如 GDPR、PCI-DSS 等等.
iThome鐵人賽
看影片追技術